Hierarchical connected graph model for implementation of event management design

ABSTRACT

An automated method and system for the implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment in which events are defined based on a connected graph model. Event handling information for each event type to be monitored is used to customize a plurality of rule templates for each type within an event source, where the event source is a hardware component, an application software component or an operating system platform. A plurality of event relationship network rules are verified to ensure they do not violate an event protocol. A hierarchical class definition and naming structure is generated from the plurality of event relationship network rules for each event source. Event management rules are then generated automatically for each event type from the event relationship network rules and the rule templates. The event management rules are loaded into a rule-based event manager. The performance of the rule-based event manager is then monitored.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is related to and contains common disclosurewith co-pending and commonly assigned patent application “System,Method, and Protocol for Automated Implementation of Event Managementand Monitoring System”, Ser. No. 09/488,689, filed Jan. 20, 2000. Thecopending patent application is hereby incorporated by reference intothis description as fully as if here represented in full.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

TECHNICAL FIELD

The present invention is generally related to computer systemsmanagement. More particularly, the present invention relates to a methodand system for the automated implementation of event management designand monitoring for a distributed computing environment.

BACKGROUND

System and network problems are complex and can surface in manydifferent forms. Even a simple problem can leave behind a complex eventtrail. This can result in excessive confusion in problem determinationefforts and unnecessary down time. However, in a well-tuned eventmanagement environment, event messages from sources such as applicationsoftware, database monitors, system hardware and network managementsystems can often be linked together, or “correlated,” to identify theroot cause of a problem. Correlation minimizes resources required toresolve the problem and reduce the resulting cost incurred.

The system and network management software industry is focusingincreased attention on products that offer support for the disciplinesof distributed monitoring and event management. All major systemsmanagement vendors are aggressively marketing products that promiseimproved capabilities in the area of enterprise systems management.There are many products that are currently available in the market.Products include Tivoli Systems' Tivoli Enterprise Console (TEC) andNetView, Computer Associates' CA UniCenter, Hewlett-Packard's OpenViewand Event Correlation Service, BMC's Software Patrol, CommandPost andMAXM products and VERITAS' NerveCenter Pro. The invention is describedin the context of the Tivoli TEC as an exemplary platform, but theinvention is not limited to the TEC platform. Those skilled in the artwill realize that many modifications and adaptations to the presentinvention are possible, and may even be desirable, in certaincircumstances and are considered part of the present invention.

While computer networking customers may choose a broad range of eventmanagement product alternatives, there has been virtually no attentiongiven by vendors of event management and monitoring products to developmethodologies and tools that assist the customers in effectivelyrelating these event management and monitoring technologies to thespecifics of their systems and distributed computing environments. Asthe individual customer's systems and distributed computing environmenttypically generate at least hundreds, if not thousands, of unique eventmessages, without systematic approaches to the tailored implementationof event management, and monitoring technologies, the resulting value tothe user of these products is significantly reduced.

For the foregoing reasons, there is a need for a system and method thatbridge the gap between the customer's unique systems and distributedcomputing event environments and the capabilities of an event managementproduct.

SUMMARY OF THE INVENTION

This invention describes a set of linked activities and supportingautomation tools that provide for the analysis and documentation of acustomer's systems and distributed computing network monitoring andevent processing requirements. This methodology is designed as afront-end to effective implementation of event management products suchas Tivoli Enterprise Console (TEC), which is a platform described hereinfor exemplary purposes only. This methodology is open, i.e., capable offront-ending the implementation of any distributed monitoring or eventmanagement product, and the invention is not limited to any specificproducts. The output of the methodology includes a set of designdocuments that serve as input to effective customization of monitoringand event processing facilities and the development of complex eventcorrelation rules. The methodology is supported by a set of personalcomputer-based analysis and documentation tools. This specification alsodescribes a software implementation of the result of such methodology,thus preventing an ad hoc approach by individual implementers.

Event Management Design (EMD) is a process developed by IBM Corporationto define the policies and procedures for managing the flow of events ina distributed computing environment. This encompasses the identificationof events, filtering practices, and correlation analysis. The process isproduct independent. At the end of the design, the client is presentedwith a set of spreadsheets and graphical representations for everysource of events in their particular environment. The spreadsheetscontain the listings of all events, their enterprise significance, theevent significance, and their necessity for correlational analysis. Theresulting drawings, using a product such as Visio, are graphicrepresentations of the correlations. These two documents provide all thenecessary information for implementing the design as a practicalsolution.

IBM has further extended EMD to include a design implementation asdescribed in co-pending patent application Ser. No. 09/488,689 which isincorporated by reference herein. This invention provides extensions tothe functionality of the tools used in EMD. It includes a spreadsheetthat is used to aid in the development of Basic Recording of Objects inC (BAROC) files. Once certain detailed information is added to thissheet, it automatically builds the BAROC files, using whatever classnames are provided. The drawing diagrams include code that allows forthe generation of Tivoli Enterprise Console (TEC) rules, using specifiedbasic rule templates developed by the EMD implementor. The new drawingcode propagates the templates with appropriate class names as determinedfrom the drawings, as well as adding in status and severity changes,timing delays, and locations of scripts to be executed.

There is a single drawing file for each type of unique event source(e.g., hardware device, operating system platform, application). Theentire suite of correlation drawings define an Event RelationshipNetwork (ERN). The ERN includes a series of pages which show the subsetof correlation relationships. Each of these pages is called a subnet.Subnets may link to other subnets, spanning as many pages as required tofully represent the set of correlational relationships. To a certainextent, the set of events on a given subnet is somewhat arbitrary. Thereis a physical limitation to the number of events that can be placed onany given page, and the break from page to page is the decision of theimplementor. On the other hand, a subnet may contain a complete logicalset of relationships, especially when it does not span to any otherpages.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of a correlation diagram having a singleevent with a clearing event.

FIG. 2 illustrates an example of a correlation diagram having a singlechain of events with clearing events.

FIG. 3 illustrates an example of a complex correlation diagram.

FIG. 4 illustrates a subnet descendant class structure of the presentinvention.

FIG. 5 illustrates a subnet ancestor class structure of the presentinvention.

FIG. 6 illustrates the complex correlation diagram of FIG. 3 with pathidentification numbers added.

FIG. 7 illustrates the complex correlation diagram of FIG. 3 with pathidentification and sequence identification numbers added.

FIG. 8 illustrates the processing logic to define an Event RelationshipNetwork (ERN) in accordance with an exemplary embodiment of the presentinvention.

FIG. 9 illustrates the processing logic for generation of BAROC classesin accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The Tivoli Enterprise Console is used in the following description asthe operating platform to facilitate understanding of the presentinvention. Tivoli's Enterprise Console is a powerful event managementand automation application that provides rules-based event correlationfor various system components including network, hardware, database, andapplications. It offers a centralized, global view of a distributedcomputing enterprise, while ensuring high availability of applicationsand computing resources. The Enterprise Console has three primaryfeatures that distinguish it from other products: event integration,event processing, and event response and notification. The EnterpriseConsole receives, processes, and automatically responds to systemevents, such as a database server being down, a network connection beinglost, or a batch processing job completing successfully. It acts as acentral collection point for alarms and events from a variety ofsources.

In a classic Tivoli implementation, the relationship of each event inthe correlational chain with each and every other event in the chain hasto be considered. As such, a simple information function can be definedthat determines the number of relationships that must be known andimplemented for any given chain of events. If I(fn)n represents theinformation function for a set of n related events, then a classicimplementation requires that the total number of states to be known is:I(fn)n=n(n−1)

However, the event relationship can be treated not as a linear flow ofevents, but rather as a hierarchical connected graph. These graphs aredefined as hierarchical since any event potentially contains(implicitly) the information of all the preceding events. If this werenot the case, then correlational analysis could not be performed since,by definition, the events would share no common information, and wouldthen be random, unrelated occurrences. By examining the set of events asa connected graph, the amount of information required to understand anindividual event's relationship to any other event in its connectednetwork can be reduced. If n_(i) represents an element in the chain, andp_(i) represents the number of paths the element is connected to withinthe graph, and if s=1 is defined to be the sequence position along thegraph, and by default a single condition of information, then the totalnumber of conditions that need to be known for any element is:$\begin{matrix}{{{I({fn})}n_{i}} = {p_{i} + s}} \\{= {p_{i} + 1}}\end{matrix}$

For a chain of x events, the total number of states can be defined tobe:ΣI(fn)n _(i) for i=1 to x

If a chain of events is considered, starting with a single root causeevent, which then has two branches with each branch containing fourresultant events, then the following results illustrate the advantage ofthe present invention:

-   -   1. For a traditional Tivoli implementation, the total number of        states that need to be known is: $\begin{matrix}        {{{I({fn})}n} = {{n\left( {n - 1} \right)}.}} \\        {= {9(8)}} \\        {= 72.}        \end{matrix}$

In the case of a hierarchical connected graph, the number of states thatneed to be known is: $\begin{matrix}{{\sum\limits^{\quad}\quad{{I({fn})}n\quad{for}{\quad\quad}i}} = {1\quad{to}{\quad\quad}x}} \\{= {3 + 2 + 2 + 2 + 2 + 2 + 2 + 2 + 2}} \\{= 21.}\end{matrix}$

The first element represents the root cause (two branches plus onepositional information equals three states). Since all other events onlyexist on a single path, they each have one branch plus one positionequals two states. The propagation of this path and sequence informationis done automatically by an EMD/IT tool, based on the constructsdescribed herein.

Of the two driving purposes of TEC monitoring, i.e., 1) correlation todetermine root cause, and 2) automated response to events, only thecorrelation problem is considered in this invention. In the presentcontext, correlation analysis is defined as establishing a set ofrelationships where the ultimate causal event can be determined. This isthe primary purpose of the TEC logic engine. Automated response to acausal event is not inherently built into the TEC code, but rather isthe use of appropriate scripts executed in response to the determinationof the causal event. As such, the scripts are external to the TEC code,and may vary among different implementations, depending on the systemmanagement process. The development of automated scripts is a separateprocess-driven function from correlation analysis.

The key elements of the present invention are as follows:

-   -   1. definition of events based on a connected graph model;    -   2. hierarchical naming convention to be used in the BAROC (Class        Definition) files;    -   3. informational slot definitions required to effectively        perform a correlation (root cause) analysis;    -   4. a basic ruleset template that handles all correlations; and    -   5. modifications to the software toolset described in co-pending        patent application, Ser. No. 09/488,689 to automate the        correlation process.

The present invention has a number of advantages as described in thisparagraph. BAROC file class definition structure and naming structureare standardized. The naming conventions and structure are integratedinto the logical design resulting from EMD. The logical flow of eventcorrelation is totally reflected in the BAROC files. Any support personcan now work through the logical structure without having access to theoriginal EMD material. Path and sequence identification (ID) searches todetermine event status is more efficient than current methods permit. Itreduces the requirement to search the entire event cache for multipleevents. By integrating the EMD results, BAROC files and rule sets, asystem is created that lends itself to well-governed change managementprocedures. No changes can be made on any single component withoutaffecting the others. As such, any change will require a comprehensivereview of the logical structure, and the implications for theimplementation. Documentation of changes is a requisite to maintain theintegrity of the integration. By reducing to six the number of essentialtemplates, implementation can be faster, and the skill level required toimplement is reduced accordingly. A rulebase and BAROC structure arecreated that are consistent across the enterprise.

In order to make the most efficient use of the logic engine, only oneevent within a given set of causal relationships can be available forcorrelation at any given time. All other events will have some aspect oftheir status changed to remove them from future correlation analysis.There are many ways in which this can be achieved. The event can bedropped, closed, its severity changed, or a new slot can be created forall events which can be flagged for its status as a correlationcandidate. The ultimate goal is that at any given time, a console can beviewed and the only events appearing would be the best estimate of acausal event at that given time.

The description of the logical flow of events in a given system makesuse of the following definitions:

-   -   Autonomous Events: These are isolated events. In other words,        they can have no causal events, nor can they be a proximate        cause for any other event. There can also be no clearing events        for autonomous events. As such, these events will never appear        in a Visio diagram, as there is no logic flow associated with        their existence. All autonomous events are handled by a single        rule as defined by policy, i.e., duplicate detection,        escalation, trouble ticketing, etc.    -   Primary Event: This can also be defined as the root cause event.        It can have no precedent events, but may have any number of        ancillary events as a result of its existence.    -   Primary/Secondary Event: This event can be either a causal        event, or can be the result of some other event distal to the        root cause event.    -   Secondary Event: This event can only result from some other        event distal to the root cause event. It can never occur        spontaneously, nor can it be the causal event for any other        event.    -   Clearing Event: This event signals a return to some defined        steady state or normal status. A single clearing event can clear        multiple events. A clearing event can never have a causal        precedent.    -   Subnet: A subnet is the set of events with appropriate logical        flow completely diagrammed. It is represented by a single page        within an ERN. A subnet can be autonomous, causal, or secondary        to other subnets, and by inference, other events.    -   Connector: The connector identifies the direction of logical        flow.

Using these definitions we can now redefine the several types of eventsas follows:

-   -   Autonomous Event: has no connectors associated with it.    -   Primary Event (P): can have n connectors flowing away from it;        must have zero connectors flowing into it, with the exception of        a connector from a clearing event.    -   Primary/Secondary Event (P/S): can have n connectors flowing        into it; can have m connectors flowing out of it.    -   Secondary Event (S): can have n connectors flowing into it; must        have zero connectors flowing out from it.    -   Clearing Event (C): can have n connectors flowing out from it;        must have zero connectors flowing into it.

Subnets can be defined under the same requirements. As such, there canbe autonomous subnets, primary subnets, primary/secondary subnets, orsecondary subnets. There is no such thing as a clearing subnet.

FIG. 1 illustrates an example of a single event with a clearing event.This is probably the simplest type of correlation possible. A singleevent occurs, and since it is neither caused by any other event, nordoes it cause any other event, it is by definition a primary event. Theonly event associated with it is a clearing event that signals a returnto normal events.

FIG. 2 illustrates an example of a single chain of events with clearingevents. This represents a more typical system of correlation, wherethere is a single chain of causal events, and a set of explicitlydefined clearing events. It should be noted that the event that clearsboth the primary/secondary event and the secondary event is normallyrepresented in Visio as only clearing the primary/secondary event, sinceclearing of the secondary event is implied by the logical event flow.The explicit clearing in this case is a requirement under the automationsystem currently used by the EMD implementation in Tivoli EnterpriseConsole (TEC). The above system better expresses the definition of asubnet, where there is a complete set of events and logical flowdesigned. A point to consider, which is described further below, is thatonly the causal chain of events are required for correlation analysis,since the clearing events are restricted to the local subnet. As such,the concept of a path or paths of causal events within a subnet isimportant to bear in mind.

FIG. 3 illustrates an example of a complex correlation diagram.Intrinsic to this is the internal subnet, which consists of a singleprimary event, multiple primary/secondary and secondary events. Subnet Arepresents a causal subnet to one chain of logical flow, while Subnet Bis a secondary subnet resultant from a single primary/secondary event.The logical flow illustrates the possibility of multiple paths from anyparticular event, as well as the possibility for multiple flow into anygiven event. This example provides all the necessary complexity toillustrate the principles for event management design of the presentinvention.

The necessary and sufficient conditions for correlation analysis are asfollows:

-   -   1. the position of any event on a logical directed graph can be        defined by two terms—path identification and sequence        identification;    -   2. since the events may belong to multiple paths, the path        identification must be a list of integers, conceptually, this is        the set of all paths that flow through any given event;    -   3. the sequence identification is a single integer that defines        the relative position of the event on the path or paths.

Events can then be redefined in the following expressions of path ID andsequence ID:

-   -   Primary Event: Path ID={1,2,3, . . . n}; Sequence ID=0. Since        the event is the root cause, it can be defined as its own class,        and all other events flowing from it become a subclass of it.        This accelerates the search process.    -   Primary/Secondary Event: Path ID={1,2,3, . . . n}; Sequence ID        ε{n, n+1, . . . m}.    -   Secondary Event: Path ID={1,2,3, . . . n}; Sequence ID=maximum        integer value for any of the paths of which it is a member.    -   Clearing Event: Path ID={−1,−2,−3 . . . −n}; Sequence ID=0. The        negative path ID is required to signal that this is a clearing        event, and not a candidate for root cause correlation.

Implicit to this is that any event that is cleared by this event hasknowledge of the negative path ID associated with it.

Therefore, the only necessary condition required to determine therelative causal status of an event is as follows:

-   Step 1: Is the event in the path of a known event?    -   If yes, go to step 2.    -   If no, the event is the current primary event.-   Step 2: What is the sequence ID of the event?

If the event sequence number is greater than the known event in thepath, then the event is a secondary event, and is removed from furthercorrelational analysis. If the event sequence number is less than theknown event in the path, then the event is the current primary event,and the previous known event is removed from further correlationalanalysis. It is necessary at this time to reiterate that only one eventwithin a given path will remain open for correlation at any given time.

The above-described meta-algorithm is sufficient to determine the status(i.e., primary or secondary) of any event within a given subnet. Aproblem occurs when multiple subnets are introduced. Logically, theabove algorithm can be extended through all connected subnets, but theproblem becomes one of propagating all the path IDs in a consistentmanner. This is not a true NP-hard problem, but is bounded by a verylarge polynomial time signature. However, by synthesizing the subnetnames with the BAROC class definitions, the search process can beminimized to class structure only.

Unfortunately, simply identifying a subnet as a BAROC class is notsufficient. It is not inconceivable, and is actually probable, that onlyone path within a subnet leads to another subnet, and there may be otherevents within the primary subnet that should not be correlated with thesecondary subnet. If all events in that subnet were events defined asdescendant to the metaclass named for the subnet, then the process wouldresult in spurious correlations. As such, a structure for BAROC classnames and hierarchy needs to be defined that reflects the logical flowof events. The following is an exemplary structure for BAROC classnaming.

-   -   ERN_Class: All events within an event source (Lotus Notes, AIX,        Cisco) become members of this class.    -   ERN_Autonomous: All autonomous events go in this class, since        they are handled by a single rule that handles issues like        duplicate detection, trouble ticketing, etc. This is a        descendant class of Event_Class.    -   Subnet Class: All events in the subnet become members of this        class. It is also a descendant class of ERN_Class.    -   Subnet Clearing: All clearing events are in this class. This is        a descendant class of ERN_Class.

If the subnet has no connections to other subnets, then this is thefinest resolution necessary. All internal correlations are dependent onpath ID and sequence ID, so there will be no searching of classes beyondthe Subnet_Class level. If the subnet does connect to other subnets,then the following class structures must be incorporated:

-   -   Subnet_Descendant#: If elements of the subnet are secondary to        events on another subnet, than all events in the direct flow        from the primary subnet entry point are members of this class.        It is a descendant class of ERN_Class. The # value is merely        indicative that there may be multiple flows within the subnet        that need to be considered as separate classes. The subnet        descendant class structure is illustrated in FIG. 4.    -   Subnet_Ancestor#: This is the logical inverse of        Subnet_Descendant. However, it poses some unique problems. The        general definition is that if elements of a subnet are primary        to another subnet, then those elements are a member of the class        Subnet_Ancestor. These may be either descendant to ERN_Class or        Subnet_Descendant, depending on the logical structure. Unlike        Subnet_Descendant, not everything in the flow can be placed into        one class. The problem comes when there are branches in the        logical flow that lead to multiple subnets. In order to make        class naming discrete, the following structure must be used. A        nodal event is defined as one that has n paths flowing out of        it. A proximal nodal event is one that is closer to the root        cause event of the entire path, while a distal nodal event is        one that is farther away. The terminal event is the event where        the path flows to the next subnet, and is essentially a        specialized distal nodal event. Events are then clustered into        Subnet_Ancestor classes by following a simple rule. All events        assigned to a specific Subnet_Ancestor are from a distal nodal        event to the next most proximal nodal event. However, the        cluster does not include that proximal event. The subnet        ancestor class structure is illustrated in FIG. 5.

The correlation template described in co-pending patent application,Ser. No. 09/488,689 is modified as described below:

-   -   1. The following slots need to be defined in a BAROC file        immediately descendant from root.baroc (the ancestral class        definition for all events): path_id, sequence_id,        descendant_class, and ancestral_class. The path_id will be a        list of integers, the sequence_id is a single integer, and the        descendant_class and ancestral_class are both a list of string        names as defined in the BAROC file.    -   2. For any event on a subnet which has either primary or        secondary subnets, and where that event lies in a logic flow        that it connects to those subnets, it will have its        ancestral_class slot populated with a list of all        Subnet_Ancestor names for all classes which are primary to it        and lie on the logical flows. The converse situation is used for        Subnet_Descendant to populate the descendant_class slot.    -   3. Path_ID slot is propagated with the list of all the path        numbers that the event is relevant to within its own ERN. An        example is illustrated in FIG. 6 and described in the discussion        on the propagation of path ID numbers below.    -   4. Sequence_ID slot is filled with the appropriate sequence        number for that path. An example is illustrated in FIG. 7 and        described in the discussion of sequence ID numbers below.

The generic correlation template becomes:

-   Step 1: For any event of class within Subnet_(‘)Ancestor;    -   if present, make the current event secondary, and remove from        future correlational analysis.-   Step 2: For any event of class within Subnet_Descendant,    -   if present, make the current event the primary event, and remove        the older event from future correlational analysis.-   Step 3: For any event on the subnet (Subnet_Class) where the Path_ID    of the current event intersects the Path_ID of the older event;    -   if the current event sequence_ID<older event sequence_ID, make        the current event primary and remove the older event from future        correlational analysis;    -   if the current event sequence_ID>older event sequence_ID, remove        the current event from future correlational analysis, as it is a        secondary event.-   Step 4: If all of the above conditions fail, then de facto this is    the primary event.

This describes the most general case for analysis. If the event had beenidentified in the EMD design as a true primary event, then step 1, andthe second half of step 3, can be removed from the analysis, since bydefinition a true primary event can never be secondary to anything else.Similarly, for a true secondary event, step 2, and the first half ofstep 3, can be removed since a secondary event can never have any eventsfollowing it.

All templates can also include conditions for duplicate detection,trouble ticket forwarding, scripts to be fired, etc. These conditionsare determined through a final workshop with the appropriate subjectmatter experts (SMEs) and follow a template similar to the document inthe appendix.

The propagation of path ID numbers is as follows:

-   Step 1: Path ID numbers are contained in the set {1, 2, n+1 . . .    m}.-   Step 2: Starting at the root event of the ERN (either a primary or    primary/secondary event) proceed to the first nodal event. The path    leading in by default is path 1. At the nodal event, one path    leading out continues to be the inherited path coming in. The    remaining paths are assigned an ascending sequence of path IDs.-   Step 3: Proceed to the next nodal event on any path and repeat the    procedure. Note that no path ID number can be reused. You must    always assign the next path number in the sequence.-   Step 4: Back propagate the paths. For example, consider a simple two    branch system. The events on path 1 that are precedent to the nodal    event where path 2 arises are, by definition, also members of    path 2. Therefore their path_id slot must contain both numbers in    its list.

FIG. 6 illustrates the complex correlation diagram of FIG. 3 with pathID numbers added. The propagation of sequence ID numbers is as follows:

-   Step 1: Sequence ID numbers are contained in the set {1,2, n+1 . . .    m}. Each event has one unique ID number.-   Step 2: Starting at the root event for the ERN, assign the sequence    ID numbers down one complete path. Return to the first nodal event,    and continue to assign the numbers for that path, increasing from    the current sequence ID of that nodal event. For example, if the    nodal event has a sequence ID of 3, then the next element down any    path must be 4. This process is repeated until complete.-   Step 3: The only deviation occurs if one event is fed by two paths.    At this point, that event should take the greater of the two values,    and any events that follow it in the logical sequence should be    increased accordingly. It is not required that the sequence ID's be    a perfect n+1 increment, only that the greater than/less than    relationships be maintained along any path.

FIG. 7 illustrates the complex correlation diagram of FIG. 3 with pathID and sequence ID numbers added.

The procedures for automated rule generation extensions to themethodology described in co-pending patent application, Ser. No.09/488,689 are as follows:

-   Step 1: The current methodology propagates a BAROC page using the    event names as class names. It separates the autonomous and    correlation candidate events. This facility needs to be retained for    autonomous events. The BAROC file for correlated events is generated    from the Visio drawings, propagating the appropriate slots.-   Step 2: Meta_classes need to be named as per the defined convention.-   Step 3: Visio diagrams currently verify the ERN for proper use of    connectors, shapes, and subnet links. This process should be    repeated.-   Step 4: The Visio program then prompts for default values related to    trouble ticketing, duplicate detection, status and severity changes,    time to search the event cache, and locations of scripts to be    executed. These values come from the final workshop with the subject    matter experts (SMEs). It also requests the location of the    templates to be used.-   Step 5: The Visio program then defines the path and sequence ID    numbers, and back propagates them into the appropriate parts of the    BAROC file.-   Step 6: The Visio program identifies primary and secondary subnets,    and defines the ancestor and descendant classes as appropriate, and    propagates those names into the respective slots on the BAROC file.-   Step 7: The Visio program then generates the automated rules based    on the assigned values and templates.-   Step 8: The spreadsheet generates the BAROC files from the populated    spreadsheet.-   Step 9: The rule set and BAROC files are given a reality check by    the implementor. If everything appears adequate, they are loaded for    testing.

FIG. 8 illustrates the processing logic for the generation of ERNs thatinclude BAROC classes. This is an extension of the processing logic forthe generation of ERNs described in co-pending patent application, Ser.No. 09/488,689, previously incorporated by reference. Processing startsin logic block 800 with the completion of event management questionnaire820. The completed questionnaire is then used to customize and updaterule templates for each event type within the event source as indicatedin logic block 802. Customizing or updating the rule templates in logicblock 802 includes adding, modifying and deleting rule actions andcommands to perform the event management behavior desired by aparticular customer. Once the behavior is specified, the tool fills inevent names, subnet names, and related values as script names.

In logic block 804, the drawing files with ERNs are examined to verifythat that the ERNs do not violate any protocols. This is followed indecision block 808 with a determination as to whether or not the ERNs inthe generated ERN verification file have been successfully verified. Ifunsuccessful, the ERNs are fixed as indicated in logic block 806 beforegoing through re-verification. The ERNs 850 are then used in logic block810 to generate BAROC classes (using the processing logic illustrated inFIG. 9) for each event source. Next, in logic block 812, rules aregenerated for each event type within the event source automatically fromthe ERNs, rule templates, and default property files 860. The solutionis then deployed and monitored as indicated in logic block 814.

FIG. 9 illustrates the processing logic for the automated generation ofBAROC files from ERNs, corresponding to logic block 810 in FIG. 8.Processing starts in logic block 900 which indicates that events on asubnet are assigned to a superclass with the name of the subnet. Inlogic block 902, connected events that are on the same subnet areassigned a path number. This step is followed in decision block 904 witha test for whether or not a branch point has been reached. If it has,then a new path number is assigned to the branch and the path number isadded to events earlier in the sequence than the branch point. This listis then appended to the path_id slot for each event. These acts areindicated in logic block 906. If a branch point has not been reached, astested for in decision block 904, then incrementing sequence numbers areassigned to each event and added to the sequence_id list as indicated inlogic block 908.

The next step in the processing logic of FIG. 9 is the test for a priorconnected subnet in decision block 910. If there is a prior connectedsubnet, then in logic block 912, the connected events on this subnetthat lead to the subsequent subnet are determined, this subset of eventsis assigned to a superclass of Subnet_Ancestor, and the superclass isadded to the ancestor slot of the original subnet events. If there is noprior connected subnet, processing continues as indicated in decisionblock 914 with a determination of whether or not there is a subsequentconnected subnet. If there is subsequent connected subnet, then the actsindicated in logic block 916 are performed. These include adetermination of the connected events on this subnet that follow fromthe prior subnet. This subset of events is assigned to a superclass ofSubnet_Descendant, and the superclass is added to the descendant slot ofthe original subnet events. If there are no subsequent connected subnetsin decsion block 914, the BAROC classes are written to a file asindicated in logic block 918.

The following is a template for a primary/secondary event. Elementsenclosed in { } are variables that are assigned by the subject matterexpert (SME) for implementation. As such, changes in severity, status,administrators, etc. are then automatically filled in by the tool tocreate a working rule. rule: ‘{ernname}_primary_secondary_event’: ( /*Instantiate the required variable to perform correlation analysis withinthe event.  * The determination of the state PS defines this rule asspecific for  primary/secondary events  */ event: _ps_event of_class‘{ernname}_Event’ where [state: equals ‘PS’, hostname: _hostname, date:_date, subnet: _subnet, path id: _path_id, sequence_id: _sequence_id,ancestor: _ancestor, descendant: _descendant, clearpath: _clearpath], /*This is a conditional test if a clearing event, due to networkvariations, has arrived prior to the  * event that it clear.  * Thisalso demonstrates the simple correlation algorithm for clearing  events,and could be used  * as the basis for a clearing rule.  *  * Thespecification of the subnet equality defines that the event is one of a set of clearing events  * that could possibly occur within a givensubnet. The path_id, is  required for more specific  * correlation.  * * The instersection of the path_id and clearpath is suffcient to definethe  complete clearing  * correlation.  */ reception_action:‘Check_Clearing_Event’: ( first_instance (event: _clr_event of_class‘{ernname}_Event’ where [subnet: equals_subnet state: equals ‘C’,origin: equals_origin, hostname: equals_hostname, status: within [‘ACK’,‘OPEN’], path_id: _clr_path_id ]), intersect(_clearpath, _clr_path_id),set_event_status(_ps_event,{status1}), set_event_severity(_ps_event,{severity1}), set_event_administrator(_ps_event, {administrator}), /* *exec_prog(notification of clear), */ commit_set ), /* This action is acorrelation to determine if the arriving event is a secondary event toan existing  * root cause that may exist on another subnet. The entirecorrelation is  defined in the call to search  * the cache for an eventwithin the metaclasses defined in the  ancestor slot.  */reception_action: ‘Check_ancestor_Subnets’: ( first_instance(event:_anc_event of_class within_ancestor where [severity: outside[‘HARMLESS’], status: within [‘ACK’, ‘OPEN’]]),set_event_status(_ps_event, {status2}), set_event_severity(_ps_event,{severity1}), set event_administrator(_ps_event, {administrator}),link_effect_to_cause( ps_event, _anc_event), /* *exec_prog(“notification of secondary status”) */ commit_set ), /* Thisaction determines if the event under examination is secondary to eventson the same subnet  * as itself.  * The subnet matching conditions aredefined by the equality check on the  subnet slot.  *  * The correlationoccurs in two statements. The intersection of the list of  pathsdetermines if there  * is one path in common between the two events. Ifthis condition is  satisfied, then the success of  * the relationshipsbetween the sequence id's will define the existing  event as a secondaryone to  * an already exiting root cause.  */ action:‘Check_ERN_Relations_Secondary’: ( first_instance(event: _related_eventof_class ‘{ernname)_Event’ where [origin: equals _origin, hostname:equals_hostname, subnet: equals _subnet, state: within [‘PS’, ‘P’],path_id: rel_path_id, sequence_id: relsequence_id outside[_sequence_id], status: within [‘ACK’, ‘OPEN’]]), intersect(_path_id,_rel_path_id), _sequence_id > _rel_sequence_id,set_event_status(_ps_event, {status2}), set_event_severity(_ps_event,(severity1}), set_event_administrator(_ps event, {administrator}),link_effect_to_cause( _ps_event, _related_event), /* *exec_prog(notification of secondary status), */ commit_set ), /* Thisaction is a correlation to determine if the arriving event is a primaryevent to an existing root  * cause event that may exist on anothersubnet. The entire correlation is  defined in the call to search  * thecache for an event within the metaclasses defined in the  descendantslot.  */ reception_action: ‘Check_Descendant_Subnets’: (first_instance(event: _desc_event of_class_within_descendant where[severity: outside [‘HARMLESS’], status: within [‘ACK’, ‘OPEN’]]),set_event_status(_desc_event, {status2}) set_event_severity(_desc_event,{severity1}), set_event_administrator(_desc_event, {administrator}),link_effect_to_cause(_desc_event, _ps_event) /* *exec_prog(“notification of root cause status”) ), */ This actiondetermines if the event under examination is primary to events on thesame subnet  * as itself.  * The subnet matching conditions are definedby the equality  check on the subnet slot.  *  * The correlation occursin two statements. The intersection of the list of  paths determines ifthere  * is one path in common between the two events. If this conditionis  satisfied, then the success of  * the relationships between thesequence id's will define the existing  event as a primary one to an  *already existing root cause.  */ reception_action:‘Check_ERN_Relations_Primary’: ( first_instance(event: _related_eventof_class ‘{ernname}_Event’ where [origin: equals_origin, hostname:equals_hostname, subnet: equals_subnet, state: within [‘PS’, ‘S’],path_id: _rel_path_id, sequence_id: _rel_sequence_id outside[_sequence_id], status: within [‘ACK’, ‘OPEN’]]), intersect(_path_id,_rel_path_id), _sequence_id < _rel_sequence_id,set_event_status(_related_event, {status2}),set_event_severity(_related_event, {severity1}),set_event_administrator(_related_event, {administrator}),link_effect_to_cause(_related_event, _ps_event) /* *exec_prog(“notification of root cause status”) */ ), /* If all of theabove conditions have failed, then we may assume that the event arrivingis,  * in effect, a root cause event at this time. As such, we couldnotify  immediately on this event.  */ reception_action:‘notify_on_primary’: ( /* * exec_prog(“notification of root causestatus”), */ commit_set ) ).

Obviously, there are any number of actions that can be taken atdifferent levels. This is only one possible example, and is set by thepolicy workshop with the SMEs. A further implication is that the rulesfor primary events contain only the lower half of this rule, whilesecondary events contain the upper half. In a uniform environment, whereall event sources are handled in an identical fashion and all possibletypes of events exist, there are a total of six rule sets: duplicatedetection and trouble ticketing; autonomous events; primary events;primary/secondary events; secondary events; and clearing events.

The current state of the EMD-IT tool, while automating certain aspectsof implementing an Event Management Design, has two limitations. Theimplementor is still required to create the ruleset templates to handlecorrelation, and to generate a rule for every type of event (primary,primary/secondary, secondary, and clearing event) for each subnet withinthe ERN. As such, there are a large number of rules generated, and theimplementor is still required to develop the bulk of the code to docorrelation. Also, while there is facility to generate BAROC files, thisis a manual procedure to establish any hierarchical information.

This methodology provides a template with all the sufficient code tohandle correlational analysis. The implementor only needs to addspecific actions after the correlation is complete. These actions arecomparatively simple and require little training to implement. Becauseof the nature of this type of correlation, only four rules are requiredfor the entire ERN, rather than four rules for each rule on the ERN.Since the structure of the BAROC files in a well-mannered hierarchy isrequisite for this model, BAROC file generation is now completelyautomated.

The present invention can be realized in software or a combination ofhardware and software. Any kind of computer system or other apparatusadapted for carrying out the methods described herein is suited. Atypical combination of hardware and software could be a general purposecomputer system with a computer program that, when loaded and executed,controls the computer system such that it carries out the methodsdescribed herein. The present invention can also be embedded in acomputer program product, which includes all the features enabling theimplementation of the methods described herein, and which, when loadedin a computer system, is able to carry out these methods.

Computer program instructions or computer program in the present contextmeans any expression, in any language, code or notation, or a set ofinstructions intended to cause a system having an information processingcapability to perform a particular function, either directly or wheneither or both of the following occur: a) conversion to anotherlanguage, code or notation; b) reproduction in a different materialform.

Those skilled in the art will appreciate that many modifications to thepreferred embodiment of the present invention are possible withoutdeparting from the spirit and scope of the present invention. Inaddition, it is possible to use some of the features of the presentinvention without the corresponding use of the other features.Accordingly, the foregoing description of the preferred embodiment isprovided for purpose of illustrating the principles of the presentinvention and not in limitation thereof, since the scope of the presentinvention is defined solely by the appended claims.

1. A method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment, comprising the acts of: inputting event handling information for each event type to be monitored; customizing a plurality of rule templates for each event type within an event source; verifying that the plurality of event relationship network rules do not violate an event protocol; generating a hierarchical class definition structure and naming structure from the plurality of event relationship network rules for each event source; and generating a plurality of event management rules for each event type automatically from the event relationship network rules and the rule templates.
 2. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 further comprising the acts of loading the plurality of event management rules into a rule-based event manager.
 3. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 2 further comprising the act of monitoring performance of the rule-based event manager in the distributed computing environment.
 4. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 wherein the event sources include one or more of a hardware device, an operating system, and a software application.
 5. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 wherein the event relationship network includes a series of drawing pages that depict subsets of correlation relationships.
 6. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 5 wherein each page of the event relationship network is a subnet comprising a set of events.
 7. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 6 wherein each subnet can link to other subnets and span the number of pages required to represent the set of correlational relationships.
 8. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 wherein the events are defined based on a connected graph model.
 9. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 wherein the act of generating a hierarchical class definition structure comprises the act of automatically building Basic Recording of Objects in C (BAROC) files.
 10. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 9 wherein each event is redefined using a path identification number and a sequence identification number.
 11. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 10 wherein a position of any event on a logical connected graph of events is determine by a path identification and a sequence identification.
 12. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 11 wherein the path identification is a list of integers that represent the set of all paths that flow through an event.
 13. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 11 wherein the sequence identification is a single integer that represents a relative position of an event on a path.
 14. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 further comprising a plurality of rule sets to handle each event.
 15. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 14 wherein the plurality of rule sets includes duplicate detection and trouble ticketing, autonomous events, primary events, primary/secondary events, secondary events and clearing events.
 16. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 15 wherein an autonomous event is an isolated event that is not a proximate cause for any other event.
 17. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 15 wherein a primary event is an event that is a root cause event that has no precedent event and can have any number of ancillary resulting events.
 18. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 15 wherein a primary/secondary event is one that can be a causal event or the result of another event distal to a root cause event.
 19. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 15 wherein a secondary event is an event that can result only from another event that is distal to a root cause event.
 20. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 15 wherein a clearing event is an event that signals a return to a steady state condition by clearing at least one event.
 21. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 16 wherein an autonomous event is handled by a single rule defined by a policy.
 22. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 7 wherein each subnet comprises any one of an autonomous subnet, a primary subnet, a primary/secondary subnet and a secondary subnet.
 23. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 10 wherein if the event sequence number is less than that of a known event in a path, then the event is a current primary event and a previous primary event is removed from further correlation analysis.
 24. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 10 wherein if the event sequence number is greater than that of a known event in a path, then the event is a secondary event and is removed from further correlational analysis.
 25. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 1 wherein the act of customizing a plurality of rule templates comprises adding, modifying and deleting rule actions and commands to perform the event management behavior specified by an end user.
 26. A method for the automated generation of a class definition and naming structure from an event relationship network represented by a hierarchical connected graph to perform correlation analysis in a distributed computing environment, comprising the acts of: assigning events in a subnet to a superclass defined with the same name as the subnet; assigning a path number to connected events in the same subnet; determining if a branch point has been reached in the connected graph; if a branch point has been reached, assigning a new path number to the branch, adding the assigned path number to events that are earlier in the sequence than the branch point, and appending a list of events and assigned path numbers to a path identification slot for each event; and if a branch point has not been reached, incrementing a sequence number that is assigned to each event and adding the event sequence numbers to a sequence identification list.
 27. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 26 further comprising the act of determining if there exists a prior connected subnet for a current subnet.
 28. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 27 further comprising the acts of: determining the subset of connected events on the prior connected subnet that lead to the current subnet; assigning the subset of events to a subnet ancestor superclass; and adding the subnet ancestor superclass to an ancestor slot of the current subnet events.
 29. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 27 further comprising the act of determining if there is a subsequent connected subnet for a current subnet.
 30. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 29 further comprising the acts of: determining the subset of connected events on the subsequent connected subnet that follow from the current subnet; assigning the subset of events to a subnet descendant superclass; and adding the subnet descendant superclass to a descendant slot of the current subnet events.
 31. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 29 further comprising the act of writing a plurality of generated classes to a data file.
 32. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 28 wherein the subnet ancestor class contains events that are primary to another subnet.
 33. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 32 wherein each event assigned to a subnet ancestor class is from a distal nodal event to a next most proximal nodal event on an event path.
 34. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 33 wherein a nodal event is an event that has a plurality of paths flowing from the event.
 35. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 34 wherein the distal nodal event is defined as an event that is farther away from a root cause event than a specified event on the event path.
 36. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 34 wherein a proximal nodal event is defined as an event that is closer to a root cause event than a specified event on the event path.
 37. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 30 wherein the subnet descendant class contains events that are in a direct flow from a primary subnet entry point.
 38. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 26 further comprising the act of generating a generic correlation template.
 39. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 38 further comprising the acts of defining a path identification slot, a sequence identification slot, a descendant class and an ancestor class in a data file immediately descendant from a root cause event.
 40. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 39 wherein the path identification slot is propagated with a list of path numbers that an event is relevant to in the event relationship network.
 41. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 39 wherein the sequence identification slot is filled with a sequence number for the path.
 42. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 39 wherein for any event on a subnet which includes a primary subnet and that lies in a logical flow connected to the primary subnet, populating the ancestor class slot with a list of all subnet ancestor class names which are primary to the event and lie on the logical flow.
 43. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 39 wherein for any event on a subnet which includes a secondary subnet and that lies in a logical flow connected to the secondary event, populating the descendant class slot with a list of all subnet descendant class names which are secondary to the event and lie on the logical flow.
 44. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 38 wherein the act of generating a generic correlation template comprises the acts of: for an event of a class within a subnet ancestor class: making a current event on the subnet a secondary event; and removing the current event from correlation analysis; for an event of a class within a subnet descendant class: making the current event on the subnet a primary event; and removing the current event from correlation analysis; for an older event on the subnet in which the path identification of the current event intersects the path identification of the older event: making the current event on the subnet a primary event and removing it from correlation analysis, if the sequence identification of the current event is less than the sequence identification of the older event; and making the current event on the subnet a secondary event and removing it from correlation analysis, if the sequence identification of the current event is greater than the sequence identification of the older event.
 45. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 40 wherein the propagation of path identification numbers includes the acts of: starting at a root node of the event relationship network, proceeding to a nodal event and defining a path leading in to the nodal event a path identification number of one; at the nodal event, continuing the inherited path leading in as one path leading out from the nodal event and assigning each remaining path leading out from the nodal event an ascending sequence of path identification numbers; proceeding to a next nodal event on any path leading out and repeating the acts performed at the nodal event of assigning each remaining path leading out from the nodal event an ascending sequence of path identification numbers; and propagating the path identification numbers backwards to ensure that events on a path precedent to the nodal event are contained in the list for the path identification slot.
 46. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 41 wherein the propagation of sequence identification numbers includes the acts of: starting at a root node of the event relationship network, assigning the sequence numbers down a complete path; for each nodal event, continuing to assign sequence numbers for each node down any path by increasing a current sequence identification number of each nodal event; and if an event is fed by more than one incoming path, assigning the event a sequence number that is the highest of each incoming path and increasing the sequence identification numbers of any events that follow a current nodal event in the logical sequence.
 47. A computer readable medium containing a computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment, the computer program product comprising: program instructions that enable inputting event handling information for each event type to be monitored; program instructions that customize a plurality of rule templates for each event type within an event source; program instructions that verify that the plurality of event relationship network rules do not violate an event protocol; program instructions that generate a hierarchical class definition structure and naming structure from the plurality of event relationship network rules for each event source; and program instructions that generate a plurality of event management rules for each event type automatically from the event relationship network rules and the rule templates.
 48. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 47 further comprising program instructions that load the plurality of event management rules into a rule-based event manager.
 49. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 48 further comprising program instructions that monitor performance of the rule-based event manager in the distributed computing environment.
 50. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 47 further comprising program instructions that define events based on a connected graph model.
 51. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 47 wherein the program instructions that generate a hierarchical class definition structure comprise program instructions that automatically build Basic Recording of Objects in C (BAROC) files.
 52. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 51 further comprising program instructions that redefine each event using a path identification number and a sequence identification number.
 53. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 52 further comprising program instructions that determine a position of any event on a logical connected graph of events by a path identification and a sequence identification.
 54. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 47 further comprising program instructions that define a plurality of rule sets to handle each event.
 55. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 54 wherein the plurality of defined rule sets includes duplicate detection and trouble ticketing, autonomous events, primary events, primary/secondary events, secondary events and clearing events.
 56. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 52 further comprising program instructions that determine if the event sequence number is less than that of a known event in a path, and if so, identify the event as a current primary event and remove a previous primary event from further correlation analysis.
 57. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 52 further comprising program instructions that determine if the event sequence number is greater than that of a known event in a path, and if so, identify the event as a secondary event and remove the event from further correlational analysis.
 58. The computer program product for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 47 wherein the program instructions that customize a plurality of rule templates further comprise program instructions that add, modify and delete rule actions and commands to perform the event management behavior specified by an end user.
 59. A computer readable medium containing a computer program product for the automated generation of a class definition and naming structure from an event relationship network represented by a hierarchical connected graph to perform correlation analysis in a distributed computing environment, the computer program product comprising: program instructions that assign events in a subnet to a superclass defined with the same name as the subnet; program instructions that assign a path number to connected events in the same subnet; program instructions that determine if a branch point has been reached in the connected graph; program instructions that assign a new path number to the branch, add the assigned path number to events that are earlier in the sequence than the branch point, and append a list of events and assigned path numbers to a path identification slot for each event, if a branch point has been reached; and program instructions that increment a sequence number that is assigned to each event and add the event sequence numbers to a sequence identification list, if a branch point has not been reached.
 60. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 59 further comprising program instructions that determine if there exists a prior connected subnet for a current subnet.
 61. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 60 further comprising: program instructions that determine the subset of connected events on the prior connected subnet that lead to the current subnet; program instructions that assign the subset of events to a subnet ancestor superclass; and program instructions that add the subnet ancestor superclass to an ancestor slot of the current subnet events.
 62. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 60 further comprising program instructions that determine if there is a subsequent connected subnet for a current subnet.
 63. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 62 further comprising: program instructions that determine the subset of connected events on the subsequent connected subnet that follow from the current subnet; program instructions that assign the subset of events to a subnet descendant superclass; and program instructions that add the subnet descendant superclass to a descendant slot of the current subnet events.
 64. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 62 further comprising program instructions that write a plurality of generated classes to a data file.
 65. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 61 wherein the subnet ancestor class contains events that are primary to another subnet.
 66. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 59 further comprising program instructions that generate a generic correlation template.
 67. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 66 further comprising program instructions that define a path identification slot, a sequence identification slot, a descendant class and an ancestor class in a data file immediately descendant from a root cause event.
 68. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 67 further comprising program instructions that propagate the path identification slot with a list of path numbers that an event is relevant to in the event relationship network.
 69. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 67 wherein for any event on a subnet which includes a primary subnet and that lies in a logical flow connected to the primary subnet, program instructions that populate the ancestor class slot with a list of all subnet ancestor class names which are primary to the event and lie on the logical flow.
 70. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 67 wherein for any event on a subnet which includes a secondary subnet and that lies in a logical flow connected to the secondary event, program instructions that populate the descendant class slot with a list of all subnet descendant class names which are secondary to the event and lie on the logical flow.
 71. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 66 wherein the program instructions that generate a generic correlation template comprise: for an event of a class within a subnet ancestor class: program instructions that make a current event on the subnet a secondary event; and program instructions that remove the current event from correlation analysis; for an event of a class within a subnet descendant class: program instructions that make the current event on the subnet a primary event; and program instructions that remove the current event from correlation analysis; for an older event on the subnet in which the path identification of the current event intersects the path identification of the older event: program instructions that make the current event on the subnet a primary event and remove it from correlation analysis, if the sequence identification of the current event is less than the sequence identification of the older event; and program instructions that make the current event on the subnet a secondary event and remove it from correlation analysis, if the sequence identification of the current event is greater than the sequence identification of the older event.
 72. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 68 wherein the program instructions that propagate path identification numbers includes: program instructions that, starting at a root node of the event relationship network, proceed to a nodal event and define a path leading in to the nodal event with a path identification number of one; program instructions that, for the nodal event, continue the inherited path leading in as one path leading out from the nodal event and assign each remaining path leading out from the nodal event an ascending sequence of path identification numbers; program instructions that proceed to a next nodal event on any path leading out from the nodal event and assign each remaining path leading out from the next nodal event an ascending sequence of path identification numbers; and program instructions that propagate the path identification numbers backwards to ensure that events on a path precedent to the nodal event are contained in the list for the path identification slot.
 73. The computer program product for the automated generation of a class definition and naming structure from an event relationship network of claim 41 wherein the program instructions that propagate sequence identification numbers includes: program instructions that, starting at a root node of the event relationship network, assign the sequence numbers down a complete path; program instructions that, for each nodal event, continue to assign sequence numbers for each node down any path by increasing a current sequence identification number of each nodal event; and if an event is fed by more than one incoming path, program instructions that assign the event a sequence number that is the highest of each incoming path and increase the sequence identification numbers of any events that follow a current nodal event in the logical sequence.
 74. A system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment, comprising: an input component that receives event handling information for each event type to be monitored; a customization component that customizes a plurality of rule templates for each event type within an event source; a verification component that verifies the plurality of event relationship network rules do not violate an event protocol; a class generation component that generates a hierarchical class definition structure and naming structure from the plurality of event relationship network rules for each event source; and a rule generation component that generates a plurality of event management rules for each event type automatically from the event relationship network rules and the rule templates.
 75. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 further comprising a component that loads the plurality of event management rules into a rule-based event manager.
 76. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 75 further comprising a component that monitors performance of the rule-based event manager in the distributed computing environment.
 77. The method for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 wherein the event sources include one or more of a hardware device, an operating system, and a software application.
 78. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 wherein the events are defined based on a connected graph model.
 79. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 wherein the class generation component comprises a component that automatically builds Basic Recording of Objects in C (BAROC) files.
 80. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 78 further comprising a component that determines a position of any event on a logical connected graph of events by a path identification number and a sequence identification number.
 81. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 further comprising a component that applies a plurality of rule sets to handle each event.
 82. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 81 wherein the plurality of rule sets includes duplicate detection and trouble ticketing, autonomous events, primary events, primary/secondary events, secondary events and clearing events.
 83. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 80 further comprising a component that determines if the event sequence number is less than that of a known event in a path, and if it is, identifies the event as a current primary event and removes a previous primary event from further correlation analysis.
 84. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 80 further comprising a component that determines if the event sequence number is greater than that of a known event in a path, and if it is, identifies the event as a secondary event and removes the event from further correlational analysis.
 85. The system for the automated implementation of a hierarchical event relationship network for correlation analysis in a distributed computing environment of claim 74 wherein the customization component comprises a component that adds, modifies and deletes rule actions and commands to perform the event management behavior specified by an end user.
 86. A system for the automated generation of a class definition and naming structure from an event relationship network represented by a hierarchical connected graph to perform correlation analysis in a distributed computing environment, comprising: a component that assigns events in a subnet to a superclass defined with the same name as the subnet; a component that assigns a path number to connected events in the same subnet; a component that determines if a branch point has been reached in the connected graph; a component that assigns a new path number to the branch, adds the assigned path number to events that are earlier in the sequence than the branch point, and appends a list of events and assigned path numbers to a path identification slot for each event, if a branch point has been reached; and a component that increments a sequence number that is assigned to each event and adds the event sequence numbers to a sequence identification list, if a branch point has not been reached.
 87. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 86 further comprising a component that determines if there exists a prior connected subnet for a current subnet.
 88. The method for the automated generation of a class definition and naming structure from an event relationship network of claim 87 further comprising: a component that determines the subset of connected events on the prior connected subnet that lead to the current subnet; a component that assigns the subset of events to a subnet ancestor superclass; and a component that adds the subnet ancestor superclass to an ancestor slot of the current subnet events.
 89. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 87 further comprising a component that determines if there is a subsequent connected subnet for a current subnet.
 90. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 89 further comprising: a component that determines the subset of connected events on the subsequent connected subnet that follow from the current subnet; a component that assigns the subset of events to a subnet descendant superclass; and a component that adds the subnet descendant superclass to a descendant slot of the current subnet events.
 91. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 89 further comprising a component that writes a plurality of generated classes to a data file.
 92. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 86 further comprising a component that generates a generic correlation template.
 93. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 92 further comprising a component that defines a path identification slot, a sequence identification slot, a descendant class and an ancestor class in a data file immediately descendant from a root cause event.
 94. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 93 further comprising a component that propagates the path identification slot with a list of path numbers that an event is relevant to in the event relationship network.
 95. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 93 further comprising a component that fills the sequence identification slot with a sequence number for the path.
 96. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 93 further comprising a component that, for any event on a subnet which includes a primary subnet and that lies in a logical flow connected to the primary subnet, populates the ancestor class slot with a list of all subnet ancestor class names which are primary to the event and lie on the logical flow.
 97. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 93 further comprising a component that, for any event on a subnet which includes a secondary subnet and that lies in a logical flow connected to the secondary event, populates the descendant class slot with a list of all subnet descendant class names which are secondary to the event and lie on the logical flow.
 98. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 92 wherein the component that generates a generic correlation template comprises: for an event of a class within a subnet ancestor class: a component that makes a current event on the subnet a secondary event; and a component that removes the current event from correlation analysis; for an event of a class within a subnet descendant class: a component that makes the current event on the subnet a primary event; and a component that removes the current event from correlation analysis; for an older event on the subnet in which the path identification of the current event intersects the path identification of the older event: a component that makes the current event on the subnet a primary event and removes it from correlation analysis, if the sequence identification of the current event is less than the sequence identification of the older event; and a component that makes the current event on the subnet a secondary event and removes it from correlation analysis, if the sequence identification of the current event is greater than the sequence identification of the older event.
 99. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 94 wherein the component that propagates a of path identification numbers includes: a component that, starting at a root node of the event relationship network, proceeds to a nodal event and defines a path leading in to the nodal event with a path identification number of one; a component that, at the nodal event, continues the inherited path leading in as one path leading out from the nodal event and assigns each remaining path leading out from the nodal event an ascending sequence ofpath identification numbers; a component that proceeds to a next nodal event on any path leading out and assigns each remaining path leading out from the next nodal event an ascending sequence of path identification numbers; and a component that propagates the path identification numbers backwards to ensure that events on a path precedent to the nodal event are contained in the list for the path identification slot.
 100. The system for the automated generation of a class definition and naming structure from an event relationship network of claim 95 wherein the component that propagates sequence identification numbers includes: a component that, starting at a root node of the event relationship network, assigns the sequence numbers down a complete path; a component that, for each nodal event, continues to assign sequence numbers for each node down any path by increasing a current sequence identification number of each nodal event; and a component that, if an event is fed by more than one incoming path, assigns the event a sequence number that is the highest of each incoming path and increases the sequence identification numbers of any events that follow a current nodal event in the logical sequence. 